IMO commits in esqpanel related to the web interface and the attached javascript file should be limited to life support (eg. fixing a critical bug) or gradually removing things. I hope MAME will eventually have internal artwork (.lay files) for these and the web interface can be removed. Maybe even emu/http.* can be removed too if we have no use for it anymore.

Regarding adding digit segment SVGs to MAME:
Are/were these intellectual property?
If we're going this direction, better increase the thickness of the segments to compensate for lack of brightness. As you can see in your example screenshot, it's less readable than the real thing.

IMO commits in esqpanel related to the web interface and the attached javascript file should be limited to life support (eg. fixing a critical bug) or gradually removing things. I hope MAME will eventually have internal artwork (.lay files) for these and the web interface can be removed. Maybe even emu/http.* can be removed too if we have no use for it anymore.

I disagree: I find the web interface to be very useful. It allows someone to simulate these keyboards in a way that basically matches how one would use the real thing: with a PC running the emulator, a MIDI keyboard for the, well, keyboard input, and the control control panel available through the web interface on a tablet together with the MID keyboard.

Accessing the control panel in the web browser can be done on a phone or tablet that has a multi-touch capable display, even when people don't have a touch-capable main screen, so that makes it that much more accessible to actually use.

And the Ensoniq VFX family of keyboards certainly have button press combinations that are fairly far apart: "Preset" + "Compare" is used to show analog values, for example. So as I don't have a touch screen on my PC where I'm developing this, I can bring up the web interface in my phone to access that button combination that I would otherwise be unable to press.

Regarding adding digit segment SVGs to MAME: Are/were these intellectual property?

I took photos of the display on my keyboard, converted them to monochrome, and traced them myself.

They are also the same segments already used in the web panel.

I actually think their specific shape seems to be largely the result of the manufacturing process, rather than a specific design: if you look, the empty space between the segments is pretty constant. It looks like someone effectively looked at a character cell, and drew thick lines separating the segment, leaving the rest as the actual segments to be lit up.

If we're going this direction, better increase the thickness of the segments to compensate for lack of brightness. As you can see in your example screenshot, it's less readable than the real thing.

The brightness in the photo is rather exaggerated due to lighting and my phone camera.

I actually did some experiments when I first added the web interface, stroking the segments as well as filling them when they were lit (see https://github.com/cbrunschen/mame/blob/master/web/esqpanel/vfx/FrontPanel.js#L243); but it ended up looking wrong when compared to the real display.

I thought about this with the very similar NEC FIP8A5AR display in the external SVG artwork for the Texas Instruments Speak & Spell by adding a partial alpha 'bloom' around each segment (which would turn on, per segment, at the same time that specific segment did), sort of like:

but I don't think I ended up going that route in the end.

Here's a picture of the display in a more representative lighting level and from a more oblique angle (such as when actually standing at the keyboard to play it)

Even here, it comes across as a lot brighter in the photo than it appears in person. Even then there's very little bleeding of the light emitted by the segments outside of the segment boundaries.

The way the display is now is the closest I've been able to get it to what I experience when I use the actual keyboard. And that includes the colour: in real life, it looks more green and less blue than in the photos.

Bloom etc are also things I'd be happy to revisit after this is in place and working.

Regarding the web interface, I'd also like to add that it offers two more useful things:

1. multiple concurrent remote connections
2. panning and zooming

The multiple connections are synchronized: they show the same state, even offering visual feedback about what controls are being used on other interfaces. And they can be remote connections, which allows the actual surface you interact with to be somewhere other than on the device where mame is running - such as, as mentioned, on a phone or tablet attached to the MIDI keyboard being played.

Beyond that, within any given browser window, the user can zoom in or out, and pan the view to show all or just a selected part of the panel.

These are useful - I'd even say, important - because of the form factor of these synthesizer front panels: they use the space above the keys which is limited in depth, but offers a lot of width.

The two features above make it not just possible, but easy, to use multiple smaller devices - a couple of phones or tablets for instance - each zoomed and panned to show part of the panel, and allowing the user to interact with both of them, keeping everything in sync. They can put these right within reach, in any available space by or on the MIDI keyboard they're playing - giving full access to the front panel controls of the emulated synthesizer.

Without these, a user needs to have sufficient-large wide-aspect-ratio touchscreen display(s) connected directly to the PC on which they're running mame, and have that combination of displays within touchable reach of the MIDI keyboard they're playing.

So to me, the web interface adds some very useful functionality that I consider quite important for how I want to be able to use these synthesizers in mame. And I'm very much not in favour of removing useful functionality.

I don’t want to be going down the path of bundling images for specific display models. I’d rather keep the internal stuff generic and allow people to provide more precise representations of specific models in external artwork if they want to.

The current internal web server implementation (actually the second iteration) is problematic in many ways. But a big problem with system-specific stuff in it right now is that it’s effectively unmaintained, and hence likely to rot. It’s too far outside what most MAME developers are going to test, so realistically, it won’t be updated for code changes.

Here's an update that replaces the nec_fip80b5r layout with a more generic esq2by40_vfx one that nevertheless correctly lays out the spacing of the characters within the display. It uses an led14seg element for the 14 segments and a separate disk for the dot / decimal point, rather than using led14segsc which would add an incorrect 'comma tail', as well as a separate underscore.

The main aim of the refactoring for the VFX family was to consolidate the panel command processing into the esqpanel2x40_vfx class and thus simplifying the esqvfd2x40_vfx class. Analogougsly I also removed the essentially duplicated command processing from the FrontPanel.js code.

But in order to not remove functionality that I'm currently using, the ability to interact with the emulated keyboard, i.e., to prevent breakage of something that was fundamentally working, FrontPanel.js has to be able to handle some simpler, lower-level instructions from esqpanel2x40_vfx.

That's all that I'm doing to the web interface. It doesn't change the level of integration. If anything, the lower-level instructions would be easier to implement in something other than a web interface, since they don't require the command processing that has now been consolidated into the esqpanel2x40_vfx class, and thus would make it easier to replace the current web-based remote interface with a different one.

I've updated this to replace the web interface with a much simpler external panel device, which runs a small asio-based server thread that allows connecting a single external device and which uses a simple text-based protocol; this is heavily based on the cps2comm device. This removes the dependency on the http server from the Ensoniq keyboards.

Separately I have a small project that talks to this new external panel and presents the web interface, as a working proof of concept as well as for my own actual use. Once these changes land I will of course make that available (and am happy to share privately before that, too).

Some more updates that might please some:

Layout-based front panels.

Spacing of elements etc based on measuring my real VFX-SD and SD-1/32.

VFX:

VFX-SD:

SD-1 (also SD-1/32):

These work together with the external panel (which is no longer web based, as before), such that each shows any buttons that are pressed the other, and of course also the Volume and Data Entry sliders.

The panels are similar but different enough that I actually write a small program that can generate all three variants.

Any comments would be greatly appreciated.

Wow! These are looking amazing!

And, to be honest, it was the very first time I was able to try playing music with these drivers and they sound fantastic as well! When they lacked internal layout, they were counter-intuitive to use and the web front-end was too hard to setup (I remember I had tried and failed!).

Don't get me wrong! I think the web-based UI has its legitimate uses as you already described, and we should not close that door. But having functional internal layout is more important, so that more people can easily use it. And I see this PR moving in the right direction. Great work being done here!

I'm glad you like the panels! I do too.

I've never had any trouble accessing the web frontend: I build MAME, run one of the VFX-family of keyboards with the -http flag , and then point a web browser at http://localhost:8080/esqpanel/FrontPanel.html which is where the esqpanel class serves its HTML.

But be that as it may, this PR now removes that integration so the point is rather moot. I can understand not wanting MAME to include something as unrelated as an entire web server.

@cuavas Where are we at on this? It looks like he's addressed all the comments, including removing the usage of the web interface, and this would be nice to have in for the branch.

I too would love to make progress on this. I believe I have addressed all the comments I've received so far. More commends and other feedback are of course also welcome!

@cuavas Some feedback on this approach would be appreciated. This would allow us to get rid of the web server entirely and Christian has a bunch of emulation improvements waiting behind it, including loading floppy images created on real hardware and having them play correctly.

@cuavas The external panel is now removed, does that work?

As there seems to be no movement on this, closing.

@cbrunschen Sometimes life has a habit of getting away from team members, and as an all-volunteer project, there's a razor-thin number of folks who actively review pull requests.

Just because your changes languished for a bit doesn't mean nobody's interested, it just means that the folks with the experience to review them have been preoccupied by other things. Burnout is a very real problem in the emulation scene, and I tend to think it better for folks to take care of themselves, their families, and their obligations on their own side of the keyboard above all else.

I understand where you're coming from, as your previous pull requests have tended to be merged in a timely manner - but it's not a personal slight against you that this one hasn't been. It's just pure luck, really, that the past ones were, and unluckiness that this one wasn't.

I would encourage you to recover your changes and reopen the pull request, because you've been doing some damn fine work on synthesizers, and it would be unfortunate to lose you as a contributor just due to what appears to be some miscommunication (or lack of communication entirely) on the part of the team.

Thank you for your kind words. But honestly, this PR was also losing its focus a bit, so taking a different tack is probably not a bad idea anyway.

I've opened #14358 that focuses solely on adding the internal layout panels, which are really the change that will be the biggest improvement for most people. It also now has a single commit, rather than a long sequence of things that partly undo each other.

Other aspects can be looked at separately, instead of in a PR that does several unrelated things in one go.

As long as you're keeping the major functional changes alive, that brings joy to my life. I just don't want you thinking that if one of your PRs languishes for a while, it's a personal slight. It's just the fickleness of life playing out. MAME isn't going to magically become the Therac-25 and start blasting people with an unbound radiation source if a particular PR doesn't go in fast enough. If you're not hearing anything, that's usually some pretty good news.